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(57) Abstract 

The functionality of portable wireless devices can be changed by providing 
programs written in a language, e.g. Java, producing a verifiable intermediary code 
(byte code). The intermediary code is translated to machine code in a node in the 
network before it is transferred to the wireless device on which it is to be executed. 
Several machine code variants of each program, translated using translators for different 
types of terminals, may exist. This enables use of the same source code for different 
terminal types and a division between software vendor, terminal vendor and network 
operator of the responsibility for carrying out the different functions involved in changing 
the functionality of a device, namely developing the source code of the program, 
compiling the source code into byte code, translating the byte code into machine code 
and transferring the machine code to the terminals on which it is to be run. 
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CHANGING FUNCTIONALITY OF A MODULE TERMINAL IN A WIRELESS NETWORK 

Technical Field 

The present invention relates to service provisioning, and in particular to service 
5 provisioning to handheld or portable terminals in wireless network. 

Description of Related Art 

The use of mobile telephones for different types of purposes is increasing. 
New types of mobile or portable terminals have been introduced, such as smart 
10 phones, message pads, personal digital assistants, intelligent pagers, etc. New termi- 
nals with increased functionality are constantly being developed. The possibility of 
upgrading the functionality of an existing portable terminal is, however, limited 
with current technology. 

15 Thus, there is a desire to be able to add functions to existing portable terminals and 
to tailor the functionality to suit the user's needs. There is a general requirement for 
portable terminals to be as small and light as possible. This limits the memory space 
available, as well as the processing speed and the power. Other factors, for example, 
the limited battery capacity, and the need for cooling must also be taken into ac- 

20 count. 

Current development of portable devices tends to place system intelligence in the 
portable device itself, rather than in a server, in order to make user interaction faster 
and to reduce the bandwidth required to transfer information and functionality. 

25 There is, however, a limit to the amount of memory and processor capacity that can 
be included in a portable device without increasing its size and weight too much. 
Thus, when designing a mobile terminal, a balance must be found between func- 
tionality requirement and the size and weight, etc., of the terminal. When determin- 
ing what to store in the mobile terminal and what to store in a node in the network, a 

30 balance must be found between the processor capacity and memory space needed in 
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the portable terminal and the bandwidth required to transfer programs and/or infor- 
mation between the network and die portable terminal. 

Also, a large number of different terminal types exist, using different hardware and 
5 software platforms. Therefore, it is desirable to make programs that are executable 
on several different platforms. 

Summary of the Invention 

It is an object of the invention to enable the execution of more advanced, or de- 
10 manding, programs in a portable device than would normally be possible with re- 
spect to the processor capacity and memory space of the portable device. 

It is an object of die invention to enable the execution of programs in a small device 
with limited processor capacity and/or memory space without reducing the process- 
15 ing speed. 

It is another object of the present invention to enable the addition of new functions, 
upgrading of functions or the complete replacement of a function package in differ- 
ent types of handheld devices, especially handheld devices adapted for use in a cel- 
20 hilar network. 

It is yet another object of the present invention to enable the execution of programs 
that do not have to be permanently stored in the terminal. 

25 These objects are achieved according to the present invention, by a method of 

changing the functionality of a mobile terminal connected by a wireless connection 
in a network, 

said functionality being implemented as programs in a programming language for 
which the source code may be compiled to an intermediary code, said intermediary 
30 code being executable and verifiable, 
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comprising the following steps: 

- translating said program into machine code using at least one translator in depend- 
ence of the hardware and software environment of at least one terminal type; 

- downloading the translated program to said mobile terminal. 

5 

The objects are also achieved by an apparatus for providing programs in a network 
comprising hosts and several different types of terminals, at least some of said ter- 
minals being connected by wireless connections, said programs being implemented 
in a programming language for which the source code may be compiled to an inter- 
10 mediary code, said intermediary code being executable and verifiable, and inter- 
preted or translated to a machine code: 
said apparatus comprising: 

- memory means for storing programs in the form of machine code, in such a way 
that they can be executed in at least one of the types of client terminals in the net- 

15 work. 

- means for transferring a program, in the form of machine code, to at least one cli- 
ent terminal. 

According to a preferred embodiment, said apparatus also comprises at least one 
20 translator for the intermediary code, said translator being adapted to at least one 
hardware and software environment used by terminals in the network. 
According to this embodiment, the method also comprises the step of translating 
said program using said at least one translator in the host before storing them. 

25 Programs may be downloaded to a terminal automatically or on a request from the 
user of the terminal. 

The method is particularly useful for portable terminals in a cellular telecommuni- 
cations network. 



30 
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According to a preferred embodiment, the appropriate program variant to be down- 
loaded to the terminal is determined on the basis of the type of terminal, for exam- 
ple, on the basis of an identity code of the terminal. 

5 The objects are also achieved by a portable terminal adapted to wireless communi- 
cation comprising a core, arranged to receive programs and/or program parts in the 
form of machine code, and to install the received programs during operation. 

The portable terminal may be arranged to provide the user with information about 
10 the dependency tree of the available programs. 

The portable terminal may also be arranged to inform die appropriate node in die 
network about its type and the subscription type with which it is currently operating, 
and other information, such as its current battery status. 

15 

According to a preferred embodiment, the portable terminal according to the inven- 
tion also receives and interprets information about whether or not a program or pro- 
gram block should be stored in the portable terminal. 

20 The most common language of the above mentioned kind today is Java. Other ex- 
amples are LISP, SmallTalk and Erlang. The source code of a Java program is not 
compiled to form machine code for a certain type of processor, but to short pseudo- 
instructions for a virtual machine, "byte code". When a program is to be executed, 
the byte code is typically downloaded to the terminal on which it is to run and then 

25 translated into machine code for said terminal. In this way, a program written in an 
interpreted language, such as Java, can be executed in any kind of computer that has 
a translator or an interpreter for the language. 



30 



Java is primarily used in Internet applications, but the advantages of interpreted lan 
guages also make them feasible for use in cellular networks. Java programs are 
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usually smaller than corresponding machine code programs and are therefore suit- 
able for mobile terminals, in which the memory space available is limited. An in- 
creasing number of mobile terminals support Java applications. 

The use of an interpreted language, such as Java, is particularly feasible in portable 
terminals because their memory space is limited. Translating the program outside of 
the terminal also reduces the requirements on processing speed and power, which 
are also limited in portable terminals. 

One main advantage of the present invention is that it enables a division of the re- 
sponsibility for carrying out the different functions involved in changing the func- 
tionality of a device. For example, a software manufacturer can be responsible for 
developing the source code of the program and for compiling the source code into 
byte code. The manufacturer of a mobile terminal can be responsible for translating 
the byte code into machine code and the network operator can be responsible for the 
transfer of the machine code to the terminals on which it is to be run. 

Interpreted languages, such as Java, have a number of advantages: 

- They make it possible to load and unload portions of code dynamically to reduce 
the amount of space needed, 

- They facilitate exchanging parts of the software since dynamic linking of programs 
is easier than with other program languages, and 

- They make it possible to run the same byte code on different processors and with 
different system architectures, so that a particular function only has to be pro- 
grammed once. 

The last two points are useful for all portable devices, and especially for portable 
devices that can communicate with a wireless network of some kind, which will be 
able to utilize all types of services offered by the network. Also, upgrading the 
software by downloading new programs will be easy, so that the terminal will not 
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become obsolete as the functions are upgraded or new services are developed. This 
will also make it easier to change from one operator to the other, in which case the 
service package of the new operator will replace the old package. It is also perceiv- 
able to let the services provided by a mobile operator change according to, for ex- 
5 ample, the time of day, the error status of the base stations in the area, the availabil- 
ity of Internet-related services, etc. 

Brief Description of the Drawings 

Figure 1 is a simplified view of a network in which the solution according to the in- 
10 vention is applied. 

Figure 2 is a more complete view of a network in which the solution according to 
the invention is applied. 

Figure 3 is a flow chart of the procedure of making a new service available in the 
network according to the invention. 
15 Figure 4 is a flow chart of the procedure of downloading a new service to a terminal 
automatically according to the invention. 

Figure 5 is a flow chart of the procedure of downloading a new service to a terminal 
on a user's request according to the invention. 

Figure 6 is an overview of how the responsibility may be divided between different 
20 participants according to the invention. 

Detailed Description of Embodiments 

Figure 1 is a simplified view of a network in which die solution according to the in- 
vention is applied, A portable terminal 1 is connected, via an air interface to a mo- 
25 bile network, through a base station 3. The base station is connected to a control 

unit 5, which is in turn connected to a network (not shown). The control unit 5 con- 
trols the base stations, and performs resource allocation functions and other func- 
tions such as switching functions in the mobile telecommunications network. In, or 
in connection to, die control unit 5, there is a program provisioning unit 9. 



30 
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The control unit 5 is connected to one or more hardware vendors' hosts 7, in turn 
connected to hosts 8, for example belonging to software vendors. Typically, the 
software vendors' hosts 8 are used for producing die source code and for compiling 
the source code into byte code. The byte code is then transferred to the hardware 
5 vendors' hosts 7, in which the byte code is translated into machine code. For this 
purpose, each hardware vendor's host 7 comprises one or more translators 1 1 for at 
least the terminal types of the particular hardware vendor. In both the hardware 
vendors' hosts 7 and die software vendors* hosts 8 test activities will normally be 
carried out in ways known in the art. 

10 

In the discussion above, the division of functions into the hardware vendors' hosts 
7, the software vendors' hosts 8 and the control unit 5 or program provisioning unit 
9 is mainly done to clarify die different functions performed. Of course the hosts 7, 

8 may also be one host in which the source code is both compiled and translated. 

15 Also, the translating function may be carried out in the program provisioning unit 9, 
in which case the program provisioning unit must comprise at least one translator 
11. 

The program provisioning unit 9 comprises a number of programs 13, 15. Each pro- 
20 gram exists in a number of variants, 13a, 13b, 13c, 15a, 15b, 15c, translated by dif- 
ferent translators 1 1 to be executable in different types of terminals 1 . 

Alternatively, only the byte code is stored In this case, when a program 13, 15 is to 
be downloaded to a portable terminal 1, this program 13, 15 is translated by the ap- 
25 propriate translator 1 1 in order to be executable on the terminal 1 and the resulting 
machine code is transmitted to the terminal 1. This procedure is discussed in detail 
in connection with Figures 4 and 5. Preferably, either the program provisioning unit 

9 or the control unit 5 comprises a selection unit comprising logic for determining 
the appropriate variant 13a, 13b, 13c, 15a, 15b, 15c of the program 13, 15 to be 
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transmitted to the terminal 1. In Figure 1 such a selection unit 17 is shown in the 
program provisioning unit. 

Figure 2 is a more extensive representation of a network in which the solution ac- 
5 cording to the invention is implemented. 

The network may comprise several networks, for example, a telecommunications 
network 21 and a data network 23, such as the Internet. In Figure 2, the telecom- 
munications network 21 is a cellular telecommunications network. The telecommu- 
10 nications network 21 comprises one or more communication units 25, such as base 
stations, connected to the network through control nodes 26 controlling the function 
of the communication units 25 and possibly other functions, such as switching 
functions in the network. The communication units 25 are adapted to wireless com- 
munication with terminals 27 in the network. 

15 

The data network 23 also comprises a number of terminals 29, 3 1, some of which 
29 are used to provide programs in the form of source code or byte code. Others 31 
may retrieve programs that are made available according to the invention. 

20 The control nodes 26 also comprise the programs to be downloaded to the terminals 
27 in the cellular network 21. In a preferred embodiment, the translated versions of 
the programs are downloaded to the control nodes 26 and stored there. The pro- 
grams may also be downloaded to the control node 26 as byte code, translated in the 
control node 26 and stored there as machine code. The programs may also be 

25 downloaded to the control node 26 and stored as byte code. In the latter case, the 
byte code must be translated to machine code when the program is to be down- 
loaded to a terminal. 



30 



As will be understood, any terminal 27, 3 1 connected to any of the networks 21, 23 
can also download programs from any host 25, 29 in any of the networks, provided 
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the functions required to do so are available in the terminal 27, 29, 3 1 or in the net- 
work. 



In this embodiment a selection unit 33 is shown in each control node 26. The selec- 
5 tion unit 33 comprises logic for selecting the appropriate variant of a program to be 
transmitted to a terminal 27. If translated programs are stored, the selection unit may 
also comprise have access to a list of the appropriate variant of a program for each 
terminal type and/or subscription. If the byte code is stored and the program trans- 
lated when it is to be transmitted, the selection unit may comprise or have access to 
10 a list specifying which translator should be used for transmission to a particular 

terminal type and/or subscription. The list may of course also state that a particular 
terminal type and/or subscription should not receive any variant of a particular pro- 
gram. 



15 Figure 3 is a flow chart of the steps taken to make a new program available in the 
network. 

Step S3 1 : The source code of die service program is written, in Java or another 

interpreted language. 
Step S32: The source code produced in step S3 1 is compiled to produce byte 
20 code. This step will normally include security checks, error detection, 

function testing, debugging, and so on. 
Step S33: The byte code produced in step S32 is downloaded to the server on 

which it should be stored This step will normally also include security 

checks. 

25 Step S34: The service programs are translated by each of the translators available. 

If the service programs are not to be run on all types of terminals, of 
course, they only have to be translated by the relevant translators. 
Step S35: The machine code resulting from step S34 are stored in a place from 
which it can be downloaded to portable terminals or other devices. 



30 
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If the storage space of the control node 26 is limited, it may not be feasible to store 
several different translated versions of the program. In this case, program may be 
stored in the form of byte code. The translation of the byte code then takes place 
when it is downloaded to the terminal, that is, steps S34 and S35 are not needed. Of 
course, it will be possible to interpret the programs before they are downloaded to 
the server on which they are to be stored, that is, to change the order of steps S33 
and S34. 



Figure 4 is a flowchart of the steps performed when a service is to be automatically 
downloaded to a portable device. 

Step S4 1 : The system informs the user that it may be desirable to download a pro- 
gram and requests an acknowledgement. This may be, for example, be- 
cause a new program, or a new version of a program has been made 
available, or because the user selects a function that requires a program 
that is not found in the user's terminal. 

Step S42: The user accepts or denies the downloading of the new program ver- 
sion. 

Step S43: If the user accepts the downloading, the appropriate program variant for 
the terminal type is selected and the program is downloaded. End of 
procedure. 

Figure 5 is a flowchart of the steps performed when a service is to be downloaded to 

a portable terminal on request of a user for execution or storing of a program. 

Step S5 1 : The user initiates a connection between the device to which the pro- 
gram should be downloaded and die server on which the program is lo- 
cated This may be done in any way known in die art, through an air 
interface or a wired connection 

Step S52: The type of terminal is determined This is preferably done automati- 
cally by the system, but if necessary, the user may specify the type of 
terminal. 
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StepS53: 



If appropriate, the user selects the program or programs to be down 
loaded. 



Step S54: 



The appropriate variant and version of the program or programs se- 
lected in step S53 is identified and downloaded. If the programs are 



5 



stored as byte code in the server, they must also be translated by the ap- 
propriate translator when being downloaded. End of procedure. 



The programs may be temporarily stored in the terminal and discarded once they 
have been executed, or the programs may be stored in the terminal. 



10 



In steps S43 and S54 the selection of the appropriate program variant may be carried 
out in the communication unit, or this information may be retrieved from the vendor 
of the terminal or the software vendor. 

15 The programs, and the appropriate variant of each program, that may be down- 
loaded to a particular terminal may be determined in dependence of the type of 
terminal and the type of subscription. 

Information about the type of subscription is found on a chip in the telephone, and 
20 is always communicated to die base station when a connection is to be set up. This 
chip, for example, the SIM card in GSM, is normally removable and may inserted in 
a number of different terminals. Thus, the type of terminal cannot be determined 
from the information on the chip. Different terminal types may, however, be able to 
run different programs, and require different variants of programs, even if the sub- 
25 scription type is die same. 

The terminal type may be determined both automatically and by manual identifica- 
tion. In the latter case, for example, each terminal type may be assigned an identifi- 
cation number, which is entered every time a program is to be downloaded. 



30 
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In a preferred embodiment, the terminal type is determined using an identity code of 
the terminal, which is a unique number identifying a wireless terminal. In GSM, for 
example the International Mobile Station Equipment Identity (IMEI) might be used. 
This number (IMEI) is stored in every mobile terminal and should in this case be 
5 transmitted by the mobile terminal to the network to indicate the variant of a pro- 
gram that whould be received. It would also be possible to define a number of ter- 
minal types and enable every terminal to inform the system about its terminal type. 
In order for this to work, information about the requirements of each series of ter- 
minals must be supplied from the manufacturers of the terminals and stored in each 

10 host, or retrieved from the manufacturer each time it is needed. This information 
may have the form of a specification of the translator that should be used for each 
terminal type. The translator may be provided by the terminal manufacturer, in 
which case the appropriate translator only has to be identified. If the terminal manu- 
facturer does not provide the translator, the requirements on the translator must be 

15 specified in detail. 

The programs to be downloaded may also be determined in dependence of other 
factors, such as the cell identity, the operator, the date or the time of the day. 

20 Automatic downloading of programs may be used, for example, in the following 
situations: 

- When a program package has been updated it may be downloaded to each termi- 
nal the first time it connects to die network after die update. 

- When the user tries to activate a service, the program associated with this service 
25 may be downloaded without the user being explicitiy informed first. 

- Certain programs may be automatically downloaded in dependence of die loca- 
tion, the time of the day, the operator, etc. 



30 



In the first case listed above, it should be possible for the user to stop the download- 
ing of software, if he/she does not want to receive new software. This may happen, 
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for example because of lack of time or because the battery is low. The downloading 
may also be stopped automatically, for example, if the battery is low. 

The situation when a subscriber is connected to another network than the one in 
5 which he/she is a subscriber, for example, when abroad, may be handled in different 
ways. In this case, the subscription information transmitted will let the system know 
that the subscriber does not belong in the current network. Even if automatic 
downloading may not be feasible, it may be desirable to allow the downloading of 
software on request 

10 

The transmission of programs from the host to the terminal may be made according 
to existing protocols for data transmission in the system concerned. For example, in 
GSM, the protocol for packet communication, Global Packet Radio Service (GPRS) 
may be used In Advanced Mobile Phone Service (AMPS) systems, The Cellular 
15 Digital Packet Data (CDPD) protocol may be used. The latter protocol also com- 
prises functions for suspending data communication when a voice call is attempted. 

The transfer of the program to the mobile terminal may be carried out in any avail- 
able channel. For transferring a program from the communication unit to one mobile 

20 terminal at a given time, a traffic channel may be used. Of course, data may be 

transmitted according to circuit switched protocols or according to packet switched 
protocols, such as GPRS in a GSM system. Also, high-speed connections involving 
more than one traffic channel may be used, for example High-Speed Circuit- 
Switched Data (HSCSD) in GSM. This will make the transfer of the program faster 

25 but will probably only be feasible at times when the traffic load in the network is 
low. 

Broadcasting may be used when the same program is to be transferred to several 
mobile terminals at the same time. In this case, control information must be added to 
30 let the mobile terminals know which terminal types are to receive the program, and 
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each terminals must comprise logic to be able to determine whether or not the pro- 
gram is intended for this particular terminal. 

In some situations it will be feasible to store parts of the program code temporarily 
5 or permanently, especially parts that are to be run several times, to avoid having to 
download them every time they are to run. For example, subroutines of a program 
that are to be run several times during the execution of the program may be stored 
temporarily in the portable terminal for as long as the program is running. Programs 
that perform important functions may be stored permanently or semipermanently. 

10 

The program parts to be stored in this way may be selected by the subscriber or by a 
node in the network, but preferably by both in cooperation. Several ways of 
achieving this are known in the art. For example, each program or program part may 
be marked, to signify if it should be stored in the mobile terminal from a system 
15 point of view, for example, to save bandwidth. To determine whether or not a pro- 
gram or program part should be stored in the mobile terminal, however, knowledge 
of the state of the terminal is also needed. Therefore, it is usually not feasible to 
store these program parts automatically, without giving the subscriber a chance to 
interrupt. 

20 

If the subscriber is to delete a program or a program part, he/she must be given in- 
formation about the dependency tree, that is, what other programs or programs part 
use the program or program part to be deleted, in order to decide if the program or 
program part should really be deleted. 

25 

The mobile terminal should therefore contain functions enabling the subscriber to 
determine whether or not a specific program or program part should be stored, and 
for how long, and providing the information needed by the subscriber to make a 
decision. 



30 
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Figure 6 illustrates the division of the responsibilities for providing the programs 
according to the invention. 

A service provider 101 provides the appropriate source code, or byte code. To do 
5 this, the service provider 101 must know the desired functionality of the service to 
be provided. Detailed information about die software and hardware environment 
provided in the terminals is not needed, but basic knowledge about, for example, the 
capacity of a terminal may be useful. 

10 A terminal manufacturer 103 provides the terminals and, usually, a translator for the 
programming language, adapted for die terminals he provides. The terminal manu- 
facturer 103 must have knowledge about the programming language used. There 
may of course be several service providers and terminal manufacturers. 

15 A network operator 105 is responsible for a mobile network 107 and for providing 
the services to subscribers 109 in the network 107. 

The responsibilities may be divided between the service provider 101, the terminal 
provider 103 and the network operator 105 in a number of different ways. For ex- 

20 ample, the service provider 101 may provide byte code to the terminal manufacturer 
103, as indicated by the arrow 111. The terminal manufacturer 103 then translates 
the byte code to machine code using the appropriate translators for the terminals he 
provides, and provides this machine code to the network operator 105 through a 
transport network 113, such as the Internet, as indicated by an arrow 1 15. Of course, 

25 the machine code could be provided in any way known in the art, for example, by 
means of a direct connection or on a floppy disk, or CD-ROM. 

Another way of dividing the responsibilities would be for the service provider 10 1 
to provide the byte code directly to die network operator 105, through die transport 
30 network 1 13, as indicated by an arrow 1 17. The terminal manufacturer 103 could 
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provide the translator to the network operator 105, and the network operator 105 
could translate the byte code into machine code. 

According to both these methods the machine code could be stored in a memory 1 19 
and provided to die subscriber 109 through die cellular network 107 when desired, 
as indicated by an arrow 121. Of course, the service provider 101 could deliver the 
source code instead of die byte code, but it is normally not desirable to deliver 
source code. 
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Claims 



LA method of changing the functionality of a mobile terminal connected by a 
wireless connection in a network, 
5 said functionality being implemented as programs in a programming language for 

which the source code may be compiled to an intermediary code, said intermedi- 
ary code being executable and verifiable, 
characterized by the steps of 

- translating said intermediary code into machine code using at least one transla- 
10 tor in dependence of the hardware and software environment of at least one 

terminal type; 

- determining the appropriate variant of the machine code to be downloaded to 
the terminal; 

- downloading the appropriate variant of the machine code to said terminal. 

15 

2. A method according to claim 1, characterized by 

- translating said program into machine code using said at least one translator; 

- storing the machine code of said programs in a host in the network 

- transferring said machine code to at least one of said terminals when desired. 

20 

3. A method according to claim 1 or 2, wherein the downloading of programs is 
initiated by a unit in the network 

4. A method according to claim 1 or 2, wherein programs are downloaded to a 
25 terminal on a request from the user of the terminal. 

5. A method according to any one of the preceding claims, wherein at least some of 
said terminals are portable terminals for use in a cellular telecommunications 
network. 
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6. A method according to any one of Ae preceding claims, characterized by the 
step of determining whether or not a program block should be stored temporarily 
or permanently in the terminal and, in this case, storing the program accordingly. 

7. A method according to any one of the preceding claims, characterized by the 
step of determining the appropriate variant of the machine code to be downloaded 
to the terminal on the basis of an identity code of the terminal; 

8. A method according to any one of the preceding claims, characterized by the step 
of detennining the appropriate variant of the machine code to be downloaded to 
the terminal on the basis of a code identifying the type of subscription. 

9. A method according to any one of the preceding claims, characterized by the 
steps of 

- for each program, determining the terminal types that can use the program; 

- translating the program using the translators relevant for said terminal types. 

10. An apparatus for providing programs in a network comprising hosts and several 
different types of terminals, at least some of said terminals being connected to 
other parts of the network by wireless connections, said programs being imple- 
mented in a programming language for which the source code may be compiled 
to an intermediary code, said intermediary code being executable and verifiable, 
and interpreted or translated to a machine code: 

said apparatus being characterized in that it comprises: 

- memory means for storing programs in the form of machine code, executable 
in at least one of the types of terminals in the network; 

- determining which machine code should be downloaded to a particular termi- 
nal on the basis of the terminal type; 

- means for transferring a program, in the form of machine code, to at least one 
terminal. 
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1 1. An apparatus according to claim 10, characterized in that it comprises transla- 
tion means for translating intermediary code into machine code in such a way 
that it can be executed in at least one type of portable terminal in a cellular net- 

5 work. 

12. An apparatus according to claim 10 or 1 1, characterized in that at least one 
type of terminal is a portable terminal connected in a cellular network. 

10 13. An apparatus according to any one of the claims 10-12, characterized in that it 
comprises means for determining title terminal types that can use each program. 

14. An apparatus according to claim 13, characterized in that it comprises means 
for determining the machine code that should be downloaded to a particular ter- 

15 minal on the basis of a serial number of the terminal. 

15. An apparatus according to any one of the claims 10-14, characterized in that it 
comprises means for determining the program that should be downloaded to a 
particular terminal on the basis of the type of subscription applying to the termi- 

20 nal. 

16. A telecommunications network comprising hosts and several different types of 
terminals, at least some of said terminals being connected to other parts of the 
network by wireless connections, characterized in that it comprises: 

25 - at least one translating means for a programming language for which the 

source code may be compiled to an intermediary code, said translating means 
being used to translate said intermediary code into machine code executable 
on at least one of said terminals; 
- memory means for storing the machine code; 
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- means for determining what programs or program versions should be down- 
loaded to a particular terminal 

- means for transferring a program, in die form of machine code, to at least one 
terminal. 



17. A telecommunications network according to claim 16, characterized in that it 
comprises means for determining what programs or program versions should be 
downloaded to a particular terminal on the basis of the terminal type. 

18. A telecommunications network according to claim 16 or 17, characterized in 
that it comprises means for determining what programs or program versions 
should be downloaded to a particular terminal on the basis of the type of sub- 
scription 

19. A portable terminal adapted to wireless communication comprising a core, 
adapted to receive programs and/or program parts in the form of machine code, 
characterized in that said core is arranged to install the received programs and/or 
program parts during operation, and that it is arranged to inform the appropriate 
node in the network about its type and/or die subscription type with which it is 
currently operating. 

20. A portable terminal according to claim 19, characterized in that it is arranged to 
provide the user with information about the dependency tree of the available pro- 
grams. 

21. A portable terminal according to claim 19 or 20, characterized in that it is ar- 
ranged to inform the appropriate node in the network about its type and the sub- 
scription type with which it is currently operating. 
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22. A portable terminal according to any one of the claims 19-21, characterized in 
that it is arranged to inform the appropriate node in the network about its current 
battery status. 



23. A portable terminal according to any one of the claims 19-22, characterized in 
that it is arranged to receive and interpret information about whether or not a 
program or program block should be stored in the portable terminal. 



WO 99/61983 



PCT/SE99/00892 



1 12 




FIG.1 




SUBSTITUTE SHEET (RULE 26) 

ISA/EP 



WO 99/61983 



PCTySE99/00892 



2/2 



WRITE SOURCE 
CODE 



I 



S32 



COMPILE TO 
BYTE CODE 



_rS33 



DOWNLOAD TO 
SERVER 



I 



'S34 



TRANSLATE TO 
MACHINE CODE 



I 



STORE MACHINE 
CODE 



S35 



( END ) 

FIG.3 



( START ) 








INFORM UStK 




TO NEW 




PROGRAM . 




V 




ACCLPT OR 




DENY 




DOWNLOADING 





DOWNLOAD TO 
TERMINAL IF 
DESIRED 

( END ) 

FIG.4 



>S43 



QtarD 



INITIATE 
CONNECTION 



4_ 




DETERMINE 




TERMINAL 




TYPE 






f 


ISELECT 




PROGRAM OR 




PROGRAMS 






r 



S52 



S53 



S54 



DOWNLOAD 

CORRECT 

VERSION 

17 



Cend ) 
FIG.5 




121^ MACHINE CODE 

® 



REQUIREMENTS 
ON SERVICE 




115' 



f MACHINE CODE 
OR TRANSLATOR 



103 



,111 

SOURCE CODE OR 
BYTE CODE 



FIG.6 



KNOWLEDGE ABOUT 

PROGRAMMING 

LANGUAGE 



SUBSTITUTE SHEET (RULE 26) 

ISA/EP 



